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1 Introduction 

We present a macro-rule-construct for convenient specification with positive/negative-condi- 
tional equations as presented in Wirth & Gramlich (1993). Though separate equations building 
up the definition of one single function are advantageous under several theoretical and practical 
aspects, this separation does not correspond to the "natural" way of defining functions. As equa- 
tional specification requires every reduction rule to be defined explicitly, various repetitions of 
common sub-expressions occur. In specifications with positive/negative-conditional equations, 
moreover, case distinctions lead to frequent numerous repetitions of only slightly changed left- 
hand sides and condition lists. This is rather tedious for the specifier and a source of errors. It 
also hides the actual structure of the specification. 

To overcome these problems we introduce a macro-rule-construct for achieving the following 
aims: 

• Concise notation: The specifier should be able to express the sharing of expressions in the 
specification language instead of having to spread copies of a common sub-expression all 
over a function's definition. 

• Logical modularization: Reduction rules for the same function should be combined and 
structured hierarchically. 

• Explicit representation of case distinctive structures: The knowledge the specifier has in 
mind should be made explicit. 

• Free choice of specification level: The language should also allow equational specification 
without using the structural features. 



To explain some ideas of our approach we will use the following rules: 

delete x nil = nil 

delete x cons y k = delete x k < — x = y 
delete x cons y k = cons y delete x k < — x ^ y 
delete x 1 =1 < — memberp x 1 ^ true 
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The main features of our macro-rule-construct are: 



• Conditions of equations are written as lists and characteristic functions as predicates. 
For example the last delete-rule above may be written 

(delete x 1) = 1 < — ( (not (memberp x 1) ) ) 

• Contraction of right-hand sides and conditions into a new "meta-term", changing the order 
of appearance: 

Instead of 

delete x cons y k = delete x k < — x = y 
we write 

(delete x (cons y k) ) = (case ( (= x y) ) (delete x k) ) 

• Introduction of match-conditions (@ VAR TERM) , which bind the variables in the term 
TERM by a required match from TERM to the value of the variable VAR. This has the ad- 
vantage that all left-hand sides of equations specifying the same function can be written in 
the same way. 

The rules of our delete-specification can now be written like this: 

(delete x 1) = (case ( (@ 1 nil) ) nil ) 

(delete x 1) = (case ( (@ 1 (cons y k) ) 

(= x y) ) (delete x k) ) 

(delete x 1) = (case ( (@ 1 (cons y k) ) 

(# x y) ) (cons y (delete x k) ) ) 

(delete x 1) = (case ( (not (memberp x 1) ) ) 1 ) 

The match- atom (@ VAR TERM) connects the rule's variable VAR with those variables 
that are introduced by TERM and may occur to the right of the match-atom. For avoiding 
reference problems, the variables in TERM must not occur to the left of ( @ VAR TERM) 
in the rule. 

This restriction can be weakened to apply only to those variables that are not properly 
influenced by some let- or match-atom. Especially VAR may occur in TERM and to the left 
of (@ VAR TERM) . E.g. in the above rules, we could replace the k with 1. In this case, the 
occurrences of VAR in the second argument of (@ VAR TERM) have the same meaning 
as the occurrences of VAR to the right of (@ VAR TERM) , which is different from the 
meaning of VAR in the first argument of (@ VAR TERM) having the same meaning as the 
occurrences of VAR to the left of (@ VAR TERM) . Thus (in case of VAR occurring in 
TERM) the borderline of the meaning of VAR in the rule goes right through the match-atom. 
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If, however, VAR does not occur in TERM, then the meaning of VAR to the left and to the 
right of the match-atom is the same. This persistence of the meaning of VAR can be useful. 
As an (not really convincing) example the first delete-rule could be written: 

(delete x 1) = (case ( (@ 1 nil)) 1) 

• A let-expression (let TERM VAR) may occur in condition lists and introduces VAR 
as a macro for TERM. 

Each of the expressions (@ VAR 2 TERMi) and (let TERM 2 VARi) binds the variables 
occurring in its second argument (TERMi, VARi, resp.) with the scope being the rest of 
the rule. If one of these variables is already bound in the context of the expression, then 
its old binding is lost in the scope of the expression. Since this is a common source for 
bugs in specifications, the specifier should^ be warned if such a re-binding occurs. E.g. 
(let (cons x 1) 1) re-binds 1 to the term (cons x 1) where 1 refers to the old 
binding of 1, which is lost for the rest of the rule. Similarly, if cons is the top symbol 
of 1, then (@ 1 (cons x 1)) binds x to the first argument of 1 and re-binds 1 to the 
second argument of the old binding of 1, which again is lost for the rest of the rule. 

The translation into rules removes an atom (let TERM 2 VARi) by substituting TERM 2 
for all occurrences of VAR X to the right of the atom. Similarly, an atom ( @ VAR 2 TERMi ) 
is removed by substituting TERMi for all occurrences of VAR 2 to the left and (unless VAR 2 
occurs in TERMi) to the right of the atomH 



• Equations with the same left-hand side are merged: 

(macro-rule (delete x 1) 
(case 

( (@ 1 nil) ) 
nil 

( (@ 1 (cons y k) ) 

(= x y) ) 
(delete x k) 

( (@ 1 (cons y k) ) 

(# x y) ) 
(cons y (delete x k) ) ) ) 



'For the specifier who really wants to write (@ 1 (cons x 1)) and does not want to be warned all the time, 
there is another match-atom having the form ( @ @ VAR 2 TERMi ) ■ It behaves similar to ( @ VAR 2 TERMi ) but 
does not warn if VAR 2 occurs in TERMi, since it un-binds VAR 2 before it binds the variables in TERMi via matching 
TERMi to the old binding of VAR 2 . 

Similarly, an atom ( @ @ VAR 2 TERMi ) is removed by substituting TERMi for all VAR 2 to the left the atom. 



Negatible conditions may be used in the (conjunctive) condition lists of case-with-else- 
and if -expressions. The two latter cases of the above macro-rule-expression can be com- 
bined into: 

( (@ 1 (cons y k) ) ) 
(if ( (= x y) ) 

(delete x k) 

(cons y (delete x k) ) ) 



For a condition list of length n + 1 an "i f "-expression saves n + 1 condition literals and 
n repetitions of the meta-term of the else-case in the specification: 

(macro-rule 1 

(if (L ... LJ 

ri) ) 

written in form of unstructured conditional equations is much longer: 

1 = r < L ... L n 

1 = r! < (not L ) 

1 = ri < (not Li) 

1 = ri < (not LJ 

For a case-with-else-expression the saving has the complexity of the product of the 
lengths of the condition lists. 

The possibility of nestling case- and if -expressions allows a quadratic saving in the 
number of condition literals: 

(macro-rule 1 
(if (L ) r 
(if (Li) n 

(if (LJ r n 

r n+l )...))) 

written in form of unstructured conditional equations is much longer: 

1 = r < L 

1 = ri < (not L ) Li 

1 = r„ < (not L ) ... (not L„_i) L n 

1 = r n+ i < (not L ) ... (not L„_i) (not LJ 
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• Propositional logic expressions using "not", "and", and "or" may occur in condition 
lists. For example 

(macro-rule 1 
(case 

(macro-rule 1 

/ ■ -p n t \ ( L * * * 

(IT ( Lq . . . h n ) . . 

is equivalent to: r 

r ° N , ( (or (not L ) ... (not L n ) ) ) 

ri) ) , , 

ri) ) 



Note that the positive/negative-conditional rule system, denoted by an or-conditioned case 
contains in general more than one conditional equation differing only in the condition part. 
As we do not provide a certain order between positive/negative-conditional equations it is 
of no importance in which order the arguments are supplied in the or-expression unless 
its negation becomes relevant due to an outer "not" or a following else-case. In the 
denoted rule system the and-expression behaves rather different: As it refers to only one 
conditional equation, the order of appearance of arguments is preserved in the condition 
list. 

• A "sequential" (or* Li ... L n ) is also placed to the specifiers disposal. This expres- 
sion guarantees, that all arguments from L to Lj_i are not fulfilled when the validity of 
hi is checked. To illustrate the difference between or and or* a characteristic function is 
specified. It tests, whether all elements in a list are equal. Here we assume ( car ( cons 
x 1) ) = x, (cdr nil) = nil (!) and (cdr (cons x 1) ) =1. The 
specification of car need not necessarily be complete. 



(macro-rule (equal-1 1) 

(if ( (or* (= (cdr 1) nil) 

(and (equal-1 (cdr 1) ) 
(= (car 1) 

(car (cdr 1) ) ) ) ) ) 

true 
false) ) 



The corresponding conditional equations for the true-case are: 

(equal-1 1) = true < (cdr 1) = nil 

(equal-1 1) = true < — (cdr 1) ^ nil, 

(equal-1 (cdr 1) ) = true, 
(car 1) = (car (cdr 1) ) 

The condition list of the second equation contains the negated first argument of or * besides 
the second one. If an or-expression were used in spite of the or* a termination problem 
would occur because this first negated condition would be removed: 

(equal-1 1) = true < (equal-1 (cdr 1) ) = true, 

(car 1) = (car (cdr 1) ) 
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As the dual of or*, an and*-expression is also included. The and- and the and*- 
expression are equivalent with respect to the positive/negative-conditional rules they de- 
note unless its negation becomes relevant due to an outer "not" or a following els e-case. 
The and*-expression should be used whenever the order of appearance of the arguments 
is relevant. 

For an and* -condition with n + 1 arguments the if -expression saves (n+1) * (n+2) / 2 
condition literals and n repetitions of the meta-term of the else-case in the specification: 



(macro-rule 1 

(if ( (and* L ... L n ) ) 

ri) ) 



written in form of unstructured conditional equations is much longer: 

1 — r < Lo • • • L n 

1 = ri < (not L ) 

1 = ri < L (not Li) 

1 = ri < L ... L n _i (not L n ) 

For a case-with-else-expression the saving has the complexity of the product of the 
squares of the numbers of arguments of the and* -expressions. 



We now give a final version of our introducing delete-specification: 

(macro-rule (delete x 1) 
(case 

( (@ 1 nil) ) 
nil 

( (@ 1 (cons y k) ) 

(let (delete x k) h) ) 
(if ( (= x y) ) 
h 

(cons y h) ) 

( (not (memberp x 1) ) ) 
1) ) 

The last case really should be omitted. It is only present to remind the cursory reader that the 
cases must be neither complementary nor complete and that their ordering is (in contrast to LISP's 
COND) relevant only for the order of the tests of an optional else-case of the case-expression. 
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All in all, this macro -rule-construct was designed as a tool for the specifier. Besides that, it 
is also useful for explicitly structuring an equational specification. This structuring must be done 
anyway: 

• It reduces the number of matching and condition tests and therefore enhances efficiency of 
rewriting. 

• More important for us is that it may exhibit the recursive construction of a function and 
therefore may help to find suitable structures for inductive proofs by giving hints for case 
distinctions and for the choice of covering sets of substitutions: 

For example, the "natural" way of proving inductive properties of the delete- 
function is to start with a covering set of substitutions given by "{li— mil}" and 
"{li— > (cons y k) }", and then to make a case distinction for the second case on whether 
"x=y" holds or not. 
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2 Examples 

In this section we give some more examples. 

Two specifications of the characteristic function of the member predicate: 

(macro-rule (memberp x 1) 
(case 

( (@ 1 nil) ) 
false 

( (@ 1 (cons y m) ) ) 
(if ( (= x y) ) 
true 

(memberp x m) ) ) ) 

denotes 

memberp xnil = false 

memberp x cons y m = true 
memberp x cons y m = memberp x m 

while 

(macro-rule (memberp x 1) 
(case 

( (@ 1 nil) ) 
false 

( (@ 1 (cons y m) ) ) 
(if ( (or (= x y) (memberp x m) ) ) 

true 

false) ) ) 

denotes 

memberp x nil = false 

memberp x cons y m = true 
memberp x cons y m = true 
memberp x cons y m = false 



x = y 
x ^ y 



x = y 

memberp x m = true 
x ^ y, memberp x m ^ true 



9 



Functions on natural numbers: 

(macro-rule (p x) 
(case 

( (@ x (s u) ) ) 
u) ) 

denotes 

p s u = u 

which is syntactically more restrictive and operationally more useful than 

(macro-rule (p x) 
( case 

( (= x (s u) ) ) 
u) ) 
which denotes 

p X = u < — X = s u . 

(macro-rule (max x y) 
(case 

( (@ x 0) ) 

y 

( (@ y 0) ) 

X 

( (@ x (s u) ) 

(@ y (s v) ) ) 
(s (max u v) ) ) ) 

(macro-rule (+ x y) 
(case 

( (@ x 0) ) 

y 

( (@ x (s u) ) ) 
(s (+ u y) ) ) ) 

(macro-rule (* x y) 
( case 

( (@ x 0) ) 


( (@ x (s u) ) ) 
(+ y (* u y) ) ) ) 



(macro-rule (pot w x) ; computes w 
( case 

( (@ x 0) ) 
(s 0) 

( (@ x (s u) ) ) 
( * w 

(pot w u) ) ) ) 



X 
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Functions on binary trees: 

(macro-rule (hight t) 
(case 

( (@ t nil) ) 


( (@ t (mk-tree 1 node r) ) ) 
(s (max (hight 1) 

(hight r) ) ) ) ) 

(macro-rule (count-nodes t) 
(case 

( (@ t nil) ) 


( (@ t (mk-tree 1 node r) ) ) 
(s (+ (count-nodes 1) 

(count-nodes r) ) ) ) ) 

(macro-rule (completep t) 
(case 

( (@ t nil) ) 
true 

( (@ t (mk-tree r node 1) ) ) 

(if ( (= (hight 1) (hight r) ) ; | this is a conjunctive condition 
(completep 1) ; | list, just like with equational 

(completep r) ) ; | rules 

true 
false) ) ) 
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3 Syntax 



The syntax of the macro-rule-construct is defined by the following context-free grammaiG 
with starting symbol <macro-rule>. Note that the sets of variable, constant, and function names 
must be mutually disjoint. Furthermore, function names must be different from "case", and 
"if" and should^ also be different from "=", "#", "clef", "@", "@@", "let", "or", "or*", 
"and", "and*", and "not". 



<term> := <variable-name> 
<constant-name> 
( <function-name> <term> + ) 



<(in-)equality-atom> := (= <term> <term>) 

| ( # <term> <term> ) 

<predicate-atom> := <term> 

<negatible-atom> := <(in-)equality-atom> 

<predicate-atom> 

<def-atom> := (def <term>) 

<basic-atom> := <negatible-atom> 
< def- atom > 

<match-atom> := (@ <variable-name> <term>) 

(@@ <variable-name> <term>) 

<let-atom> := (let <term> <variable-name>) 



< negatible-condition > 



< negatible- atom > 
(and <negatible-condition>*; 
(or <negatible-condition>*; 
(and* <negatible-condition>*J 
(or* <negatible-condition>*J 
(not <negatible-condition>) 



3 Here, " " denotes zero or more repetitions, " ... + " denotes one or more repetitions, "...|..." denotes different 
possibilities, "<...>" denotes non-terminals, and typewriter font indicates grammar terminals. 

4 This is necessary if the function is specified as characteristic function and used in a predicate-atom. 
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< general-condition > := 



<negatible-condition-list> 
<general-condition-list> 



< negatible-condition > 
<basic-atom> 
<match-atom> 
<let-atom> 

(and < general-condition > * ) 
(or < general-condition > * ) 

(and* <negatible-condition>* <general-condition> ) 
(or* <negatible-condition>* <general-condition> ) 

( <negatible-condition>* ) 

( < general-condition >* ) 



<negatible-case> 
<else> 



<case> := 



<negatible-condition-list> 
<meta-term> 

else 

<meta-term> 

<general-condition-list> 
<meta-term> 



<if-term> := 



<case-term-with-else> := 



<case-term> := 



( i f <negatible-condition-list> 
<meta-term> 
<meta-term> ) 

(case 
<negatible-case>* 
<else>) 

(case 
<case> + ) 



<meta-term> := 



<term> 
<if-term> 

<case-term-with-else> 
<case-term> 



<macro-rule> := (macro-rule <term> <meta-term>) 
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4 Semantics 

The semantics of a sequence of macro-rule-expressions is a positive/negative-conditional rule 
system. 

Let: 



META-TERM, G L G (<meta-term>) 

The denotation of the following "elementary" macro-rule-expressions is defined as follows: 
(macro-rule TERMi TERM 2 ) 
denotes the unconditional rewrite rule 
TERMx = TERM 2 
and 

(macro-rule TERMx 



(BASIC-ATOMo ••• BASIC-ATOMJ 
TERM 2 ) ) 

denotes the following rewrite rule with nonempty condition 
TERMx = TERM 2 < — BASIC-ATOM , . . . , BASIC-ATOM n 

A macro-rule-expression is non-erroneous iff it can be transformed into elementary 
macro-rule-expressions with the rewrite rules we will introduce in this section. Note that 
the semantics is declarative in so far as no precedence is imposed on the application of these 
rules. The resulting rewriting relation is confluent and Noetherian. Since all elementary 
macro-rule-expressions are irreducible, each macro-rule-expression denotes at most one 
positive/negative-conditional rule system. 



5 L,3(<sym>) denotes the set of words generated by productions of our grammar starting from the symbol 
<sym>. 



VARj G 

TERMi e 

PRED-ATOM, G 

N-Q G 

N-C-LIST, G 

BASIC-ATOM; G 

MATCH; G 

LET; G 

GEN-CONDj, G-Ci G 

CASE, G 



L G (<variable-name>)_f - 

L G (<term>) 

L G ( <predicate-atom> ) 

L G (<negatible-condition>) 

L G (<negatible-condition-list>) 

L G (<basic-atom>) 

LG(<match-atom>) 

L G (<let-atom>) 

L G (<general-condition>) 

Lc(<case>) 



(case 
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"Predicate"-Removal 

Predicates may be used as conditions. All these predicates are put into equations: 

In the context of a general or negatible condition: 

PRED-ATOM ► (= PRED-ATOM true) 



"if "-Removal 

if -expressions are replaced by "case-with-else"-expressions: 

(if N-C-LIST (case 

META-TERMi > N-C-LIST 

META-TERM 2 ) META-TERMi 

else 

META-TERM 2 ) 



"e 1 s e"-Removal 

As else-statements may cause trouble when replacing "case in case" (cf. below), they must 
be eliminated before: 

(case 

(N-Ci,i ••• N-Ci, ni ) META-TERMi 

(N-C m ,i--- N-C m ,„ m ) META-TERM m 

else META-TERM m+ i) 



(case 

(N-Ci,i ••• N-Ci, ni ) META-TERMi 

(N-C m ,i--- N-C m ,„ m ) META-TERM m 
( (or (not N-Ci 5 i) 
(not N-Ci j2 ) 

(not N-Ci, ni ) ) 

(or (not N-C m ,i) 
(not N-C m>2 ) 

(not N-C m ,„ m ) ) ) META-TERM m+1 ) 



If none of the preceding rewrite rules applies anymore, then all negatible atoms are (in-)equality 
atoms and no if - or else-expressions occur in the specification. 
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'not "-Removal 



(not (not N-C) 



(not (and N-Ci ••• N-C r 



(not (and* N-Ci •■• N-C r 



(not (or N-Ci ••• N-C n ) 



(not (or* N-Ci •■■ N-C n ) 



(not (= TERM! TERM 2 ) ) 



N-C 



(or (not N-C] 



(or* (not N-Ci) 



(and (not N-Ci) 



(and* (not N-Ci) 



(# TERM] TERM 2 ) 



(not N-C n ) 

(not N-C n ; 

(not N-C n ; 

(not N-C n ; 



(not (# TERM] TERM 2 ) 



;= TERM] TERM 2 ) 



"or"-Removal 

(case 
CASEi 

C A. S E^ 

( G _ Ci • • • G _ Cp 
(or GEN-CONDi ••• GEN-COND r ) 
G-Cp+i ■■• G-Cp_)_q) 
META-TERM 
CASE n+ i 

CASE n _|_ m ) 

i 

(case 
CASEi 

CASE n 
(G-d •• 

(G-Ci •• 
CASE n+1 

CASE n _|_ m ) 

Note that for application of this rule no 'else' may occur in the case-expression. 



G-Cp GEN-COND] G-C p+ i • • • G-C p+q ) META-TERM 
G-Cp GEN-COND r G-C p+ i • • • G~C p+q ) META-TERM 
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"or*"-Removal 



CASEx 
C A. S 

(G — Q\ m m m G~ Cp 
(or* N-Ci ••• N-C r ) 
G-Cp+i ■ ■ ■ G-Cp+g) 
META-TERM 
CASE„ +1 

CASE n _)_ m ) 



I 

(case 
CASEi 



CASE„ 



(G — C\ • • • G~Cp 
N-Ci 

G~Cp+i ' ' ' G-C p+(? ) 

META-TERM 

( G — Ci • • • G — Cp 

(not N-Ci) N-C 2 

G _ Cp+i ■ • • G-Cp+g) 

META-TERM 



(G _ C\ • • • G — Cp 
(not N-Ci) ••• (not N-C r _i) N-C r 
G~Cp + i ■•• G-Cp +(? ) 



META-TERM 
CASE ra+ i 



CASE 



n+m I 



Note that for application of this rule no 'else' may occur in the case-expression. 
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'and[*]"-Removal 



(case 
CASEi 



(case 
CASEx 



C A. S 
(G-Ci 



G-C r 



(and[*] GEN-CONDi 
G _ Cp+i • • • G-Cp+g) 
META-TERM 
CASE n+1 



GEN-COND r ) 



C A. S 
(G-Ci 

GEN-CONDi 

G _ Cp+i 
META-TERM 
CASE n+1 



G C p 

■ ■ ■ GEN-COND,. 
G-C p+q ) 



CASE ra _(_ m ) CASE n _|_ m ) 
Note that for application of this rule no 'else' may occur in the case-expression. 



"c a s e-in- c a s e"-Removal 

(case 
CASEi 

CASE m 

(G-Ci ••• G-Cp) 
(case 

(GEN-COND 1;1 ••• GEN-COND^ ) META-TERMi 

(GEN-COND rj i ••• GEN-COND rj<?r ) META-TERM r ) 
CASE m+ i 

CASE m+n ) 

i 

(case 
CASEi 

CASE m 

(G-Ci ••• G-Cp GEN-COND 1; i ••• GEN-CONDi i91 ) META-TERM! 

(G-Ci ••• G-Cp GEN-COND rjl ••• GEN-COND r)(?r ) META-TERM r 
CASE m+1 

CASE m+n ) 

Note that for application of this rule no 'else' may occur in any of the two case-expressions. 
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"@ "-Removal 

As we do not want match-atoms in our final rule-system we replace all occurrences of a match- 
variable VAR preceding a match-atom (@ VAR TERM) with the match-term TERM. If the 
match- variable does not occur in the match-term, we also have to replace all occurrences of the 
match-variable in the scope of the match-atom with the match-term. Let V(TERM) denote the set 
of variables occurring in TERM. 

If VAR G V(TERM) , then the specifier should be warned like: 

"WARNING: (@ VAR TERM) re-binds VAR" 

and we reduce: 

(@ VAR TERM) ► (@@ VAR TERM) 

Otherwise we reduce: 

(@ VAR TERM) ► (@@ VAR TERM) 

(let TERM VAR) 



"@@"-Shift-Left 

In case of V(BASIC-ATOM) n (V(term)\{var}) ^ the condition list below is erroneous. 
Otherwise we reduce: 

(G-d (G " Cl 



G C m 

BASIC-ATOM 
(@@ VAR TERM) 
G~C m+ i 



G C m 

(@@ VAR TERM) 
BAS IC-ATOM{VARi— >TERM} 
G~C m+ i 



G C m + n ) 



G-C 



m+n i 



"let "-Shift-Right 

If VAR e V(TERM) , then the specifier should be warned like: 

"WARNING: (let TERM VAR) re-binds VAR" 

The following inference rule is the dual of "@ @ "-shift- left. 

(G-d (G-d 

G _ C m G~C m 

(let TERM VAR) BAS IC-ATOM{VARi— >TERM} 

BASIC-ATOM (let TERM VAR) 

G _ C m+ i G-C m +i 

G — C m _)- n ) G _ C m -|_ ra ) 
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"let"-"@@"-Swap 

This is the only non-trivial rewrite rule. 

(G-Ci 

G — C m 

(let TERMx VARi) 
(@@ VAR 2 TERM 2 ) * 
G _ C m _|_i 

G — C m j rn ) 
with <X> defined as follows: 



:g-ci 

G _ C m 

<X> 

G _ C m+ i 

G~C m+n ) 



VARi = VAR 2 : ERROR. 

There is no reasonable semantics for this unless TERMicr = TERM 2 £cr for some £ replac- 
ing the variables of V(TERMi) fl V(TERM 2 ) with new distinct variables and a being a 
most general unifier for TERMx and TERM 2 £0 This case, however, is too unlikely and not 
important enough to give semantics for, since this would make single pass error checking 
more difficult. 

VARi e V(term 2 ) \ {var 2 }: 

<X> = (@@ VAR 2 TERM 2 ) 

The let-term is removed since VAR X is re-bound by the match-atom. Often, this will not 
be the intention of the specifier. Therefore a warning should be given. 

VARi {VAR 2 } U V(TERM 2 ): 

<X> = (@@ VAR 2 TERM 2 ) 

(let TERMi{VAR 2 f-^TERM 2 } VARi) 
This should be the normal case. 

Note that errors and warnings (case one and two) can be detected easily by one single pass over 
the specification before starting the rewriting. This allows error and warning messages to refer 
to the original macro-rule-constructs, which is necessary for being understandable for the 
specifier. 



6 <x> = (@@* v(termi)1 (J ) (let* (v(term 2 )1 (^o - )) *) would correspond to our intention. E.g. for 
(let (mt 1 y 1) k) 
(@@ k (mt hi (cons y m) h.2) ) 

we would choose £:= { y ^ z } ; a := { y ^ (cons z m) , hi 1— * 1 , h.2 1— > 1 } and get 
<X>= (@@ y (cons z m) ) (let 1 hi) (let 1 h 2 ) (let z y) . 

However, this definition would destroy the confluence of ' — ►', E.g. consider the following condition-list where 
y is an alias for u: ( (@ x (s u) ) (@ x (s y) ) ) — > 
((@@ x (s u) ) (let (s u) x) (@@ x (s y) ) (let (s y) x) ) . 
The latter condition-list reduces in two ways. First with £:={}, er := { u 1— » y } : 
— > ((@@ x (s u) ) (@@ u y) (let (s y) x)). 
Second with £ := { }, a := { y u } : 
— > ((@@ x (s u) ) (let u y) (let (s y) x)). 

Now the first version reports an error if y occurs to the left while the second does not. Furthermore, the first version 
will use the variable y in its scope while the second will use u instead. 



20 



Splitting 

(macro-rule TERM (macro-rule TERM 

(case (case CASEi) ) 

CASEx > : 

: (macro-rule TERM 

CASEJ ) (case CASEJ ) 



By application of the inference rules introduced above, all non-erroneous macro-rule-expressions 
can be transformed into the following form: 

(macro-rule TERMx 

(case (MATCHi ••• MATCH m 

BASIC-ATOMi ••• BASIC-ATOMp 
LETi ••• LETJ 
TERM 2 ) ) 

or 

(macro-rule TERMi TERM 2 ) . 

The transformation into an elementary macro-rule-expression is attained by the last three 
rules. 



"@@"-removal 

In case of V(TERMi) n (V(TERM 2 )\{VAR}) ^ the specification is erroneous. 
Otherwise we reduce: 

(macro-rule TERMi 
(case 

( (@@ VAR TERM 2 ) G-Ci ••• G-C m ) 
META-TERM) ) 

I 

(macro-rule TERMi {VARi—>TERM 2 } 
(case 

(G— Ci ■ • • G— C m ) 
META-TERM) ) 
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"let "-removal 

(case 

CASEi 



CASE m 



(G-Ci ••• G-C m (let TERMx VAR) ) TERM 2 
CASE m+ i 



CASE 



m+n 1 



I 

(case 
CASEi 



CASE m 



(G-Ci ••• G-C m ) TERM 2 {VARh^TERMi} 
CASE m+ i 



CASE 



m+n I 



"c a s e-with-empty-condition"-Removal 

(macro-rule TERMi (case () TERM 2 ) ) >■ (macro-rule TERMi TERM 2 ) 
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